This could be an interface. It'll save us few lines. This requires few additional changes in generic parameter boundaries from Endpoint to RemoteAction. This how the full interface would look like:

public interface CreateUser extends RemoteAction<CreateUserResult>, CustomIncludeAware<CreateUser> {
    CreateUser name(String name);

    CreateUser email(String email);

    CreateUser profileUrl(String profileUrl);

    CreateUser externalId(String externalId);

    CreateUser custom(Map<String, Object> custom);

    CreateUser status(String status);

    CreateUser type(String type);

    CreateUser userId(UserId userId);

    static CreateUser create(
            final PubNub pubNub,
            final TelemetryManager telemetryManager,
            final RetrofitManager retrofitManager,
            final TokenManager tokenManager) {
        final CompositeParameterEnricher compositeParameterEnricher = CompositeParameterEnricher.createDefault();
        return new CreateUserCommand(pubNub, telemetryManager, retrofitManager, tokenManager, compositeParameterEnricher);
    }
}

I will contact you to talk about this change.

Sure. Let's talk

I tried to introduce interface but is seems more easier approach to reduce code we can get rid of CreateUserCommand class and move all login from that class to CreateUser that will be changed from abstract to non abstract class. I also removed UserEndoint class.

All those fields could have generated fluent setters with lombok, just like we have for most of other implementations. It'll save us few lines. It'll look like this:

@Accessors(chain = true, fluent = true)
public final class CreateUserCommand extends CreateUser implements HavingCustomInclude<CreateUser> {
    @Setter
    private String name;

I can change it without big enthusiasm. With this construction code is more difficult to read for people that don't know lombok. But this is good chance for me to learn it :)
FYI
In SetChannelMetadataCommand and SetUUIDMetadataCommand this lombok is not used.

I'm not a fan of lombok either, but if we have it already and it's used in quite a few places we can as well just make use of it

In SetChannelMetadataCommand and SetUUIDMetadataCommand this lombok is not used.

That might have been an oversight. AFAIR it was a big big PR as well, so I might have missed something

This is an implementation so I'd make it package private. There should be no need for customer to use these

I like this idea.

I would likely see here all required parameters instead of everything being optional. That would mean that all space related methods should have spaceId at least. This could bring additional changes in other places: making it required in the *SpaceCommand and also most probably the SpaceEndpoint will no longer be necessary

I like this idea.

I knew that you'll like it :)

Seeing this catch I think we made a mistake by keeping uuid in configuration as a base field instead of UserId. We wouldn't have to have this here for simple getUserId

ok

I guess you missed final

Yes, thanks.

Shouldn't we include it everywhere where we have Body or not include it at all?

I will delete it.
I found @headers in ChannelMetadataService and UUIDMetadataService so I will delete them from there as well.

I'd use just @Data instead of these annotations

@Data introduces @Setter. I am wondering if we want to have setters for those fields?

it doesn't if you have everything final

@Data should be all right here instead of currently present

Makes sense. I will change it.

Why the return value is CreateSpaceResult and not just Space? In Kotlin we return just Space. Could you please align the return values for all new methods to what we have in Kotlin already?

I forgot that in Kotlin we get rid of status in response. I will change CreateSpaceResult to Space. Status might be inferred by Space object being present or exception being thrown
e.g. when creating space with id that already exists following exception is thrown:
{"error":{"message":"Requested resource already exists.","source":"metadata"},"status":409}

Shouldn't we have a SpaceId as a type for id field for this class?

Yes. Good catch. I will create class similar to PNObject but with no id and add:
private SpaceId id;
to Space.java.
I will also add custom interceptor to map id as String in REST response to SpaceId .

public class SpaceIdDeserializer implements JsonDeserializer {
@SneakyThrows
@OverRide
public SpaceId deserialize(JsonElement json, Type typeOfT, JsonDeserializationContext context) throws JsonParseException {
String spaceIdValue = json.getAsString();
return new SpaceId(spaceIdValue);
}
}

Same story as with Space. I think its id should have type UserId

I will add it. Thanks.

Simpler alternative

@Data
public class RemoveSpaceResult {
    private final int status;
}

Ok. I will use magic of lombok.

I think custom should not be an Object but rather should have the same type as we expect when we createSpace, so Map<String, Object>.

What would you say about this simpler version of Space?

@Data
public class Space {
    @NonNull
    private final SpaceId id;
    private final String name;
    private final String description;
    private final String status;
    private final String type;
    private final Map<String, Object> custom;
}

probably we'd need custom deserializer for SpaceId

I think this is good improvement. I guess we need to add eTag and updated field so:

@EqualsAndHashCode(onlyExplicitlyIncluded = true)
@DaTa
public class Space extends ObjectVsp {

@EqualsAndHashCode.Include
@JsonAdapter(SpaceIdDeserializer.class)
@Setter
private SpaceId id;
private String name;
private String description;
private String status;
private String type;

@Override
public Space setCustom(Map<String, Object> custom) {
    super.setCustom(custom);
    return this;
}

}

@DaTa
@accessors(chain = true)
public class ObjectVsp {

@JsonAdapter(CustomPayloadJsonInterceptor.class)
@Setter
protected Map<String, Object> custom;

protected String updated;
protected String eTag;

}

I think it should rather be an error. We are expecting body in case of successful response

Not sure what you suggest? Something like this ?
if (input.body() != null) {
return input.body().getData();
} else {
throw PubNubException.builder().pubnubError(PubNubErrorBuilder.PNERROBJ_CHANNEL_MISSING).build();
}
In case of error program will not hit this method. So return new Space() should never happen.

I was looking at PNSetChannelMetadataResult, GetChannelMetadataCommand and there empty object creation but maybe it's more precise to throw exception.